Damn Vicious Web Access

A phrase inspired from DVWA, but the current discussion has nothing to do with penetration testing. Recently, I had been suffering from immense frustration with my internet connectivity (fuck ISP! fuck!!), and only after quite a long time was I able to figure out what was the problem! An erroneous NAT64 translation at the ISP end, barring me from accessing certain IPv4-only sites (GitHub, Reddit, to name a few!). To get a comprehensive view of how an ISP provided IPv6-only (primarily) network works, one can refer Jio 5G - IPv6 only on transport.

Workaround

The simplest one would be to use a functional DNS64/NAT64 translation. To understand how this works, help yourself:

Hats off to the following public NAT64/DNS64 service providers:

You can have your own BIND9, with a grain of DoT/DoH!

The Hard Way!

For privacy concerns (hehe, boi!), and to “seemingly” convert the damn IPv6-only to IPv4-only stack, I decided to setup a VPN. Now, where to get a remote machine to host it? seriously! where?? I don’t know why I chose Google Cloud, mostly because I wasn’t able to create an Oracle Cloud free tier account (still not able to figure out, like WTF is wrong with their card verification system? fuck!!), and I was looking for some kind of always free quota! (sorry! AWS, Azure)

Setup

You need a virtual private network, right? so, learn to Create and manage VPC networks, and for my case, I chose a combo of IPv4-only with IPv4/IPv6 (dual-stack, with an external IPv6 access type)
Too rich? no?? know How to Host Your Side Projects for $0: The Ultimate GCP Free Tier Guide
2 network cards, yeah! acquaint yourself with Using a multi-nic VM as a gateway between VPCs in Google Cloud (pay special attention to IP forwarding!)
Finally, WireGuard! I leave you with 3 choices:
- Docker-WireGuard
- Setting Up a WireGuard VPN Server on Google Cloud Platform (Note: VPC Network → Firewall Rules, don’t fuck up here!)
- Stupid simple setting up WireGuard - Server and multiple peers (especially, the /32-prefix in the server’s peers’ AllowedIPs)

Fuck No!

Oh yeah! the hair tearing begins! Everything seems to be on track – VPC, Firewall, VM, sysctl (yes! just miss setting net.ipv4.ip_forward = 1, and see what a slicky ass MF it is!), WireGuard, everything configured, every syntax correct! and then, bam!! a hit right in the face! A refreshing ping from IPv4-only nic0 and, a straight “fuck you!” from the dual-stack IPv6-address beholder nic1. Give up! right? since, at this point, what was even the point of doing all this shit! in the first place? Maybe, I would have …, hadn’t I stumbled across x-yuri’s answer. So, with post-nut clarity, I began:

Unclogging the IPv6 routes:

Look for the IPv6 gateway on nic1 (ens5):
```
#!/bin/bash

ip a
ip -6 route
```

Fix the path:

#!/bin/bash

sudo ip -6 route add default via <IPv6_gateway_on_ens5> dev ens5 table 1
sudo ip -6 rule add from <IPv6_network_on_ens5> table 1

Verify:

#!/bin/bash

ip -6 rule show table 1
ip -6 route show table 1

If routing gets dirty! cleanup:

#!/bin/bash

sudo ip rule flush table 1
sudo ip rule delete from 0/0 to 0/0 table 1
sudo ip route flush table 1
sudo ip -6 rule flush table 1
sudo ip -6 rule delete from ::/0 to ::/0 table 1
sudo ip -6 route flush table 1

Optional: Create a service (so that, you don’t lose track with VM restart!)

[Unit]
Description=Fix Routing
After=network-online.target

[Service]
ExecStart=bash <path_to_shell_script>

[Install]
WantedBy=multi-user.target

Multi-Layer

The first time I executed warp-cli connect with WARP (sounds more like, “Now from the top, make it drop, that’s some WAP …”, hehe, just kidding!), I was kicked out of my own server! Had to delete and re-create the VM , fuck!! An idiot enough not to realize that “All device traffic is routed through WARP” rather than the standard local gateway. Now, as I was bent upon using Zero Trust WARP, and with split tunnels being of no help! I proceeded with warp-cli mode proxy that establishes a tunnel for use in a SOCKS5 proxy over 127.0.0.1:40000.

To utilize this mess (yeah! I still think there could have been a better way than a damn proxy! or, maybe I’m stupid!), I fired up a WireGuard interface (say, wg1), but how the fuck am I supposed to interface it with a proxy? redsocks? privoxy? maybe, but for me? hell nah! Time to go nuts? almost! Not if you know Redirecting All Container Traffic via SOCKS Proxy using tun2socks – an excellent technique of using fwmark with iptables -t mangle! For me, it was:

#!/bin/bash

tun2socks --device tun0 --proxy socks5://127.0.0.1:40000 --interface ens4
sudo ip route add default via <IPv4_gateway_on_tun0> dev tun0 metric <METRIC> table <ROUTE_TABLE>
sudo ip rule add from <IPv4_network_on_tun0> table <ROUTE_TABLE>
sudo ip rule add fwmark <FWMARK> priority <PRIORITY> table <ROUTE_TABLE>
sudo iptables -t mangle -A PREROUTING -i wg1 -p tcp -j MARK --set-mark <FWMARK>

And, as expected, I fucked up! forgetting to allow forwarding for wg1:

#!/bin/bash

sudo iptables -A FORWARD -i wg1 -j ACCEPT

Verify ip rule and iptables:

#!/bin/bash

ip rule show table <ROUTE_TABLE>
ip route show table <ROUTE_TABLE>

#!/bin/bash

sudo iptables -t mangle -vnL PREROUTING --line-numbers
sudo iptables -vnL FORWARD --line-numbers
sudo iptables -t nat -vnL POSTROUTING --line-numbers
sudo iptables-save

Ciao Adios!

Home

JustABeginning